【心得】完全無損分割無損音樂擋（關于CD，WAV，APE，FLAC，TAK間的橫向比較

樓主;緋羽殤;mon007007

推111;噓-

2017-08-25 00:06:02 編輯

cueconvert是一套方便又好用的CUE音樂檔案分割程式，它可以將單一的 APE,TTA,FLAC...等無損音樂檔案，依照 CUE 檔案中的時間資訊，按音軌切開成單一檔案，方便你日后的播放和儲存，程式簡單輕巧，編碼設定上也非常方便。

功能介紹

　　1) 支援 APE,FLAC,TAK,TTA,WV 無損音頻。 　　2) 支援新版作業(yè)系統(tǒng) Windows 7/Vista 32 位元，不支援 64 位元 ( 沒測試所以未知 )。 　　3) CUE 僅支援 （Utf-8(Bom)/ANSI）格式。 　　4) 輸出格式 MP3,WAV,APE,FLAC,TTA,TAK...等等，每個格式中都有簡單的編碼設定。 　　5) 支援簡單的檔名輸出規(guī)則。 　　6) 簡單的音樂播放功能 。 　　7) 支援 MP3、WMA 等音樂格式 ID3 標簽寫入功能 　　8) 支援 UniCode。

更新日志

　　1.修正 cue檔案時間軸辨識錯誤的問題。 　　2.修正 OGG、WMA 格式中 AlbumArist 寫入 ID3 標簽格式誤判為 Album 的問題。 　　3.修正承是在 90 bpi 中字體變大的問題。 　　4.修正無法轉換至日文或其他非正體中文資料夾的問題 　　5.修正在刪除清單時會有延遲的問題。 　　6.更改播放清單的顯示方式。 　　7.新增 CUE 檔案編碼選擇項目

APE

Monkey's Audio開發(fā)者Matthew T. Ashland穩(wěn)定版本4.34;（2018年5月2日，3個月前）類型Audio compression,;Encoder許可協議Monkey's Audio Source Code License Agreement網站www.monkeysaudio.com

Monkey's Audio，是一種常見的無損音訊壓縮編碼格式，副檔名為.ape。與有損音訊壓縮（如MP3、Ogg Vorbis或者AAC等）不同的是，Monkey's Audio壓縮時不會丟失數據。一個壓縮為Monkey's Audio的音訊文件聽起來與原文件完全一樣。Monkey's Audio文件的播放列表使用.apl。

Monkey's Audio亦可指壓縮／解壓縮Monkey's Audio文件的軟件。因其主界面上有個猴子圖樣而得名。Monkey's Audio是壓縮ape格式的重要工具；也可以對ape文件進行解壓縮。安裝該軟件時可以選擇是否向winamp添加插件，使得winamp也可以播放ape文件。通常與Monkey's Audio配合使用的軟件有Exact Audio Copy（EAC）、foobar2000等。

Monkey's Audio是一種無損音訊壓縮格式，而較之于其他無損音訊壓縮格式，有長處亦有缺陷。

Monkey's Audio壓縮比高于其他常見的無損音訊壓縮格式，約在55%上下，但編解碼速度略慢。在搜尋回放位置時，如果文件壓縮比過高，在配備較差的電腦會有延遲的現象。另外，由於它沒有提供錯誤處理的功能，若發(fā)生文件損壞，損壞位置之后的數據有可能會丟失。

Monkey's Audio是開放原始碼的免費軟體，但因其授權協議並非自由軟體而是準自由軟體（Semi-free Software）而受到排擠。因為這意味著許多基于GNU/Linux的Linux發(fā)行套件或是其他只能基于自由軟件的作業(yè)系統(tǒng)不能將其收入。較之其他使用更自由的許可證的無損音訊編碼器（如FLAC），受其他軟件的支持也更少。

因為Monkey's Audio是一種無損壓縮格式，所以不適于同有損壓縮格式相比較——這兩者有不同的目標和用途。無損壓縮的目標是能夠精確再現原文件的前提下將之壓縮到盡可能小的體積。而有損壓縮則是在丟失一部分信息的情況下，在用戶指定的體積／比特率中盡可能保持接近原來的音質。

所以，無損壓縮的音訊文件體積往往遠大于從同樣原文件壓縮而來的有損壓縮文件。例如：在壓縮CD音訊時，一個典型的Monkey's Audio文件往往有接近600～700K Bit/sec，而MP3最高不會超過320K Bit/sec，一般情況下用戶只會指定到128～192K Bit/sec。雖然它們也可能達到可以接受的音質，但不會有Monkey's Audio等無損壓縮格式般逼真。

Hydrogenaudio的Wiki提供了一個Monkey's Audio與其它無損音訊壓縮格式的全面比較。[1]

目前官方只提供Windows支援。雖然也有提供GNU/Linux和Macintosh平臺的官方支援的討論，但是沒有結果。目前只有一位名為SuperMMX的開發(fā)者于2003年7月釋出了一個非官方移植版本。它包括了供XMMS與Beep Media Player回放Monkey's Audio使用的插件。該移植本來只支援GNU/Linux，但從3.99 update 4 build 4版本開始支援Mac OS X和基于PowerPC、SPARC平臺的GNU/Linux。但是這個非官方移植計劃沒有得到官方的承認，受制于官方發(fā)行許可證的限制，其未來並不明朗。不過據稱Monkey's Audio的Win32庫可以借助Wine在GNU/Linux平臺運行。

APE是一種音訊文件格式，一般用.ape的副檔名，有時也采用.MAC的副檔名。APE格式採用無損數據壓縮，在不降低音質的前提下，能有限地壓縮WAV音軌文件，壓縮比率一般在55%左右。在音質上，相對于WMA、MP3、AAC等有損數據壓縮的格式有著絕對的優(yōu)勢。

APE文件結構是由Monkey's Audio定義的。Monkey's Audio提供軟件進行與其它音訊文件格式的轉換。通過插件，APE文件可以在foobar2000、Nullsoft的Winamp和微軟的媒體播放器等不同系統(tǒng)平臺的多媒體軟件中播放，近來越來越多的便攜式媒體播放器也較多的加入對APE文件的支援。

今天在弄音樂檔的時候，找到了一個容量異常龐大的Flac檔，結果點開來發(fā)現是整張完全沒有分割過的光碟音樂OTZ(這要怎麼聽啦)

一般碰上這種情況，很多人下意識會想用用看格式工廠來割割看啦，可是這是無損擋誒，不是那種路邊就能撿到的MP3檔案，那樣做一定會直接把音質給毀了。

急著想聽歌，然而卻找不到任何將原始檔無損切割的辦法嗎？這時候就是CUE檔出馬的時候了。

何謂CUE檔案？

有稍微接觸無損音樂檔的人，可能有時候會碰到取得的文件並不是單純的音樂檔，而是包在一個資料夾中一堆雜七雜巴看不懂的檔案。

唯一一個看起來像是音樂檔的東西點開來，發(fā)現挖勒，怎麼每一首歌都黏在一起啊？這要怎麼聽？

舉個貍子：

度，這三小？點開來我整個人都傻了，我只是想聽個音樂，貼這檔案的人是不是在耍咱啊？？

一般人都習慣的單純的音樂檔案，不管是mp3,flac,tta還是mav，總之最好是點開來就能聽的。碰上這種情況一定是當場愣住，不過只要我們分析一下這些檔案是幹嘛的，就不會感到那麼不知所措了。

大概4這樣。

所謂的CUE檔案，就是類似電子曲目單的東西。用來記錄甚麼時段，幾分幾秒幾毫秒的時候，要將音樂檔進行切割。

然並卵，就算你知道了這些，那個該死的原始檔案還是在那邊裝死啊！怎麼割啦？割X皮喔？

來，別急。CUE檔案不是你點開來就能用的，你需要下載專用的分割軟體來進行分割音樂的作業(yè)。

個人使用的是;Medieval CUE Splitter;，內建繁體中文，基本上猴子都能輕鬆的把曲子給切開來，介面大概4長這樣。

Medieval CUE Splitter是一款免費、支援繁體中文、分割速度快的APE音樂分割軟體，目前為1.2版。下載的APE無損壓縮音樂，如果一張專輯只有一個檔案，會有一個CUE檔案，用來記錄APE、FLAC音軌的起始、結束位置、歌曲名稱等資訊，必須使用CUE檔案開啟與播放音樂，才能顯示播放的曲目。下載與安裝Medieval CUE Splitter，開啟CUE檔案，就可以將整張CD的APE音樂分割為每首歌一個檔案，詳細作說明如下：

要使用Medieval CUE Splitter分割APE音樂，必須先安裝Monkey's Audio，詳見：免費WAV轉APE的軟體Monkey's Audio。

1.連結到Medieval CUE Splitter官方網站，點選「Download」。

2.選擇「儲存檔案」，點選「儲存」。

3.下載完成以後，開啟檔案總管，對著下載的檔案連續(xù)按兩下滑鼠左鍵，安裝Medieval CUE Splitter。

4.點選「Next」。

5.使用預設的安裝資料夾，點選「Next」。

6.點選「Install」。

7.安裝完成，點選「Finish」。

8.對著桌面的捷徑圖示連續(xù)按兩下滑鼠左鍵，開啟Medieval CUE Splitter。

9.Medieval CUE Splitter開啟的視窗如下圖所示。

10.點選「Language繁體中文/Traditional Chinese(A)」，將語言介面改為繁體中文。

11.點選「檔案開啟CUE檔」。

12.選擇要分割的CUE檔案，點選「開啟」。

13.開啟的檔案如下圖所示，會顯示所有歌曲，點選「編輯」的按鈕，可以更改檔案輸出的格式。

14.依自己的需要選擇與修改輸出的格式，設定完成點選「確定」。

15.點選「分割」，分割音樂。

16.選擇輸出的資料夾，點選「確定」。

17.正在分割音樂，如下圖所示。

18.分割完成，點選「確定」。

19.關閉Medieval CUE Splitter，結束音樂的分割。

20.分割完成的檔案如下圖所示。

嘿，你把CUE檔叫粗乃，它就會自動顯示出CUE上面的電子曲目表了，有沒有很棒啊？

大概就就像下面這樣。

Medieval CUE Splitter功能

; ; ;1、完美支持中文等多語言CUE文件和XMCD文件，軟件界面也有中文版；;

; ; ;2、列出全部軌道，想要哪首分割哪首，非常方便；;

; ; ;3、作方便，不需要學習 (雖然 Foobar 等播放器也有插件完成類似功能，但安裝和配置起來很麻煩)；;

; ; ;4、可以導出APE, WAV, MP3, FLAC, OGG, WMA, MPC, WV 和 TTA 等格式；;

; ; ;5、如果導出的格式是無損格式，則音質和源文件一致不會有任何改變；;

; ; ;6、軟件完全免費！

Medieval CUE Splitter中文設置方法

; ; ;Medieval CUE Splitter; 完全免費，支持多國語言，首次運行 CUE Splitter 時軟件界面為英文，你只要在在 language 中選擇“簡體中文”就可以了。

之後按下分割，它會問你要把分割的檔案放在哪個資料夾，選完之後就開始分割了，結果如下：

喔喔喔喔，你悶看，4不4很棒很簡單R？就這麼輕輕鬆鬆的切開了，傑克這真是太神奇了！

而且音質完全沒有任何毀損，真真正正，單純只是切割音軌而已。

好了，如果你手邊有這樣的檔案，那麼看到這邊就好了。

接下來我們進入正題。

空有原始檔，然而CUE檔早就不知去向的情況

發(fā)生這種情況，如果一拿到檔案就是長這樣，那麼就是檔案來源有問題。如果是你自己手殘刪掉的，牆在那邊，請自己去撞。

嘛，總之事情已經發(fā)生了，把牆撞破也沒辦法補救了，那就已死謝罪吧只好用比較費力的方式來解決了。

自己的CUE檔，自己來創(chuàng)造。

聽起來蠻中二的，不過這是真的可以做到的，下面就來講一下我們該怎麼靠自己的力量來分割已經殘廢的檔案。

今天的主角是它，射手座☆午後九時don't be late。檔案大小十分的精美，一看就知道是完全沒被分割過的原始光碟檔案呢，誒嘿~~(誒嘿你老母啦)

我當時一定是很興奮的把CUE檔案給砍了之後，直接把它丟進資料夾置之不理了。

碰到這種情況，請不要驚慌。先尋找附近離你最近的牆，腦袋用力撞下去。

先讓我們了解一下CUE檔案的性質。

其實CUE檔案只是比較特殊的文字檔案，你隨便叫出一個記事本(txt)，然後把CUE檔案拖進去，就會發(fā)現它的廬山真面目了。

舉個貍子：

這是剛剛，涼宮春日專輯的CUE檔案。把它丟進筆記本裡會長這個樣子。

邏輯沒到太差的朋友，大概已經可以看得懂CUE檔案運作的原理了，不過小弟在這邊還是幫大家弄一張詳細的圖解，像下面這樣。

邏輯都出來了，對吧？

接下來我們要做的就是把這個CUE檔案，改成那首切割檔遺失的音樂，能夠使用的格式。

FILE ;LACM-4255.tta; WAVE 這個字串給刪除，這段字的意思是音源檔案，如果你不把它刪掉，那麼不管你下面怎麼改，軟體都會跑回去切我們不需要的音樂檔。

接下來把專輯名稱、作者改成自己想要的名稱。

之後再把不需要的段落刪除，比如說我想擷取的音樂只有其中的一首，那我就只要留三個段落。

分別為：(我不需要的前段)、(我要聽的這段)、(沒有用的後段)

大概這樣分之後，點開那個你要切割的音樂檔，用耳朵去聽你要切的音樂落在幾分幾秒。

(基本上這類的檔案，曲和曲之間都會有充足的空白時間，所以很好分辨。)

將你需要的時間軸更改到記事本上，我改完後的結果如下：

沒有動到的部分，代表不會影響到最後的切割結果。相信聰明的各位，拿這張圖和上面比較一下，就知道要改些甚麼東西了。

改完之後直接存檔，就會覆蓋掉原本的CUE檔案。

將需要切割的音樂檔、更改後的CUE檔丟在同一個資料夾中，準備進行最後一道手續(xù)。

我們直接點開修改過後的CUE檔，軟體會跳出上面的視窗，要我們指定音源檔案。

由於剛剛我們把CUE檔案的音源路徑刪除了，軟體無法判別音源檔，因此會要求我們重新指定。只要直接點我們要分割的曲子就好了。

你看！出來了！

剛剛輸入的資料，就整整齊齊的呈現在這邊了。接下來直接點分割，選擇輸出資料夾就大功告成了。

結果如下：

勤修苦練，終於獲得回報。努力了那麼久，總算把這個殘廢的檔案給切割出來了，有沒有很感動啊？我感動的都快濕了，嗚嗚嗚。

為了避免以後有同樣的悲劇發(fā)生，請保留一個CUE檔案，已備未來修改方便。

那麼大概就4醬了，看完之後大家有沒有覺得醍醐灌頂？思路清晰？看完後考試都考了一百分呢？

一點都不難嘛！真的是猴子都能懂得簡單教學呢！

蛤？你跟我說看不懂？那閣下可能連.....都不如了(*???*)(*???*)(*???*)

沒有懶人包啦，就是一篇廢文，希望幫到有需要der人。

以後不要再亂砍CUE檔了啦，87

The following images are taken from the ;Dark; theme of Windows Desktop version (1300x900). Medieval CUE Splitter supports both ;Light; and ;Dark; themes, either desktop or mobile version.

By;咣輝のま裔;http://blog.sina.com.cn/s/blog_637d7cd80101pfdm.html

轉載請注明作者信息，謝謝。

;

之所以要寫這篇文章，是因為網絡上各種傳言實在太多了，以至于誤導了大眾。

為什么會有這么多的誤解呢？我認為原因有以下幾點：

1.;;;;;;;所謂天下文章一般抄，凡是對自己支持的觀點有利的，便宣傳它，夸大它，凡是對自己不利的觀點便忽略掉。

2.;;;;;;;大眾對計算機原理的不了解，導致各種主觀想法和他人說法，不經證實，便成結論。

3.;;;;;;;能肯定的就肯定他，能否定的就否定他。無法肯定與否定的，就變成了各種差不多，基本一致，基本沒差別，可能好一點。這種含糊其辭的說法，除了誤導群眾，沒有任何好處。

;

關于不同格式間音質的正確認識

先寫結論吧：

音質：CD = WAV =;各種無損格式

也就是說音質上沒有任何差別

長期保存：CD ;= WAV =;各種無損格式

通俗的講就是光盤會因為保存不當而造成數據損壞。而硬盤上的文件，除非硬盤出了問題，否則發(fā)生改變的概率極低。

解釋：

說到音質就不得不說CD

在說CD之前還是先解釋幾個相關概念：

黑膠唱片：黑膠唱片是跟CD完全不同的媒體介質，存儲的是模擬信號，需要專門的turn table設備播放。

LPCD（黑膠CD）：本質就是CD，只不過母帶的處理方式不同，采用的碟片質量更好，有利于保存而已。與黑膠唱片完全是兩個概念。

;

音頻CD（Compact Disc Digital Audio;(CDDA)），保存的是數字信號。二進制的PCM音頻數據從CD讀取到內存，再保存為硬盤中的WAV格式文件，不過是在頭部添加了一個RIFF（資源交換文件標志）信息而已，這一過程是不會產生任何損失的。如果你告訴我這個過程可能會產生錯誤的話，那我也告訴你，你直接播放CD也一樣會有錯誤，而且錯誤的可能性更大。CDDA是包含C1，C2效驗碼的，這足以檢測出發(fā)生的錯誤，并在錯誤不多的情況下恢復正確的音頻數據。

EAC在抓軌遇到錯誤的情況下，會反復重讀多次特定的音頻數據來得到正確的抓軌結果。只要EAC不在log中報告出現錯誤，抓取出來的文件都是和源文件一模一樣的。

參看：

CDDA：http://wiki.hydrogenaudio.org/index.php?title=Compact_Disc_Digital_Audio

里德-所羅門碼：

http://zh.wikipedia.org/wiki/里德-所羅門碼

;;;;;;

同一設備上直接播放CD，或者播放WAV文件，效果是完全相同的。至于不同的CD機播放CD的效果不同，那已經屬于音效不同的范疇了。當然，好的CD機確實是能夠更準確的讀取CD。但是99.9%的準確跟100%的準確在聽感上是不會有多少差別的，說白了還是播放設備對音頻還原以及音效處理的不同。

CD在長期保存的過程中，難免會有一些灰塵，污漬，劃痕。若是保存不當，音質只會隨著時間慢慢變差。類似于播放DVD視頻花屏。

;

無損格式，顧名思義，就是沒有任何損失的壓縮格式。本應是毫無懸念的東西，硬是給某些人套上了差不多的名號。

證明無損格式與WAV沒有任何差別很簡單，將wav文件轉換為各種無損格式，然后再轉換回wav，用Beyond Compare對比2進制數據，音頻數據沒有任何差別。（文件頭的一些信息可能被丟棄，比如藝術家，歌名等，這就是某些小白遇到的md5不同的問題，用foobar2000轉換的話，這些數據都不會丟失）

;;;;;;

說到這里又必需談到某些人士特別執(zhí)著的，所謂由于解碼速度WAV〉FLAC〉APE，所以聽感流暢性上：WAV〉FLAC〉APE。

;;;;;;;事實真的是這樣嗎？答案自然是否定的。

;;;;;;;其實大部分人都知道這是假的，只不過礙于那些憑空捏造出來的金耳朵，自己又沒證據否定他，于是采取了既不否定也不肯定的態(tài)度。

首先我們來看下各種壓縮格式音頻播放過程：

1.;;;;;;;從硬盤中讀取一小段音頻到內存中

2.;;;;;;;解碼為WAV音頻數據

3.;;;;;;;提交給聲音設備處理

4.;;;;;;;重復上述步驟

步驟1和步驟2都可能產生瓶頸，步驟1的瓶頸在于硬盤的讀取速度，步驟2的瓶頸在于CPU的解碼速度。

;;;;;;;我們偶爾會遇到這種情況，在打開大型游戲的瞬間或者安裝大型軟件，播放的音頻出現卡頓。正是由于這種體驗，似乎證實了上面的流暢性的說法。然而事實卻并非如此，此時的瓶頸正是硬盤滿載造成的，即便是播放WAV也一樣會出現卡頓。

播放壓縮格式的音頻都是有緩沖的，所謂緩沖就是預先解碼為WAV，Foobar2000的默認時間為1000ms，也就是說你播放的這個時刻，下一秒鐘的音頻早已解碼為WAV了（存放在內存中），所謂解碼復雜度造成的流暢度問題完全是杞人憂天。

APE的解碼速度跟FLAC比固然有差距，但是相對于當今的移動設備，播放個APE可以說是毫無壓力。即便是N年前的Nokia N73（220MHz ARM9;單核CPU）都可以播放APE。（使用谷雨影音。不過說實話，我在移動設備上從來不放無損，AAC足以）凡是用著Windows XP以上系統(tǒng)的PC也是沒有任何問題的。

;

題外話：關于緩沖長度（Buffer Length）的正確認識

如果我上面對緩沖的說法不足以讓你信服的話，讓我們來看下foobar2000官方文檔對緩沖長度的解釋：

Buffer Length

To protect playback from glitches during heavy system load or file access lag, resource-heavy operations such as decoding and DSP are always performed ahead of currently heard sound (this is not unique to foobar2000, all or nearly all media players behave this way). This setting controls the distance between decoding/DSP and output.

High buffer sizes offer stronger protection against glitches but introduce side effects such as long delay between changing DSP settings (eg. adjusting equalizer bands) and changes in sound output.

Low buffer sizes allow faster responses to DSP configuration changes at cost of higher risk of stuttering during high system load / file access lag / etc.

WARNING: Setting too low buffer length may cause certain visualizations to stop working correctly. Use of buffer lengths below 500ms is not recommended.

翻譯如下：

為了防止在系統(tǒng)負荷較重，文件訪問滯后，耗費資源的作（比如解碼和DSP）時產生的播放毛刺（譯者注：俗稱爆音，卡頓，破音等），總是預先處理當前聽到的聲音（不僅僅是foobar2000，所有或幾乎所有的媒體播放器的都是這么處理的）。此設置控制解碼/ DSP和輸出之間的距離。

高緩沖大小，提供更強大的保護，防止毛刺。但引入副作用，比如;從DSP設置改變（如調整均衡器頻段）到聲音輸出發(fā)生變化之間的長時間延遲。（譯者注：這句話的意思是你將DSP設置從A改變?yōu)锽，然后繼續(xù)播放，要經過一段延遲，聲音的播放效果才會從A變?yōu)锽，延遲的時間長度等于緩沖大小，因為這一段的聲音已經預先解碼并用DSP設置A處理了，并不會重新用DSP設置B處理，這個你自己修改下DSP設置試試就知道了。）

低緩沖大小，允許更快地響應DSP配置改變，但這以更高的聲音結巴風險為代價，在系統(tǒng)高負載，文件訪問滯后等等的時候。

警告：緩沖長度設置過低，可能會造成一些可視化效果，停止正常工作。建議不要使用低于500ms的緩沖長度。

;;;;;;

好了，真相就就在這里了，那些緩沖長度越小越好的輿論實在是太搞笑了，你連這個緩沖長度是干什么的都不知道，莫非你覺得你比foobar2000的作者更了解foobar2000？的確小的緩沖長度播放起來音效是有所不同的，不過是越小越差，因為毛刺變多了。當然也并非越大越好，因為緩沖長度到了某個長度，計算機的處理速度就不會造成瓶頸了，繼續(xù)增大也沒有任何效果。一般按foobar2000默認的1000ms到2000ms就好。

那些播放APE爆音的輿論也由此而來，說白了就是一些小白被一些所謂的音質設置優(yōu)化的金耳朵大神給殘害了，把緩沖長度設置成了最小值，自己的機器又實在不行。至于音源本身的爆音，那已經與文件格式無關了。

APE，FLAC，TAK間的對比

APE官網：http://www.monkeysaudio.com/

FLAC官網：https://xiph.org/flac/

TAK官網：http://thbeck.de/Tak/Tak.html

先寫總結：

撇開兼容性不談的話，真正優(yōu)秀的無損格式只有FLAC和TAK，APE的表現只能說是相形見絀。如果說FLAC在稍大體積領域，解碼速度無人能及的話。作為APE直接競爭對手TAK，在這個稍小的體積領域，展現出了最佳的解碼速度。然而閉源的TAK在移動設備上的兼容性為0%，這也是時至今日，APE依然無可取代的根本原因。每每談到TAK，便有恨鐵不成鋼之意。

;

在開始比較之前還是要嘮叨幾句。

如果說維基百科是講究參考與來源的中立觀點的話，那百度百科更像是幾個粉絲寫的主觀科普文章。這點在文件格式上表現的尤為突出。明星的百科也是這種特點，各種第一什么的妥妥的。百度百科當作擴展資料看看就好，不可全信。

;

首先要說的就是：碼率≠音質;碼率僅僅代表文件體積跟時間的比值

假如把WAV比做一口缸，APE，FLAC，TAK等無損格式比做桶的話，MP3等有損格式就是各種大小不同的杯子。

現在這口缸里裝了一桶水，把缸里的水倒到桶里并不會有任何損失。

如果把桶里的水倒到杯子里，那就有一些部分流失了。

再把杯子里的水倒回桶里，剩下的還是一杯水。

所以WAV跟有損音頻的轉換是不可逆的，高碼率的有損跟低碼率的有損之間的轉換也是不可逆的。

還有一點要說的就是WAV跟APE，FLAC，TAK的轉換都有不同的級別

這些級別之間的區(qū)別僅僅是編碼和解碼速度以及體積不同，對音質毫無影響

就像RAR文件壓縮方式：儲存和最好的區(qū)別一樣。

不推薦采用APE的Extra High和Insane級別，這是造成一些早期支持APE的移動設備無法正常播放的根本原因。

尤其是Insane級別，即使在電腦上播放，定位的時候也會卡一下，而且Insane級別在某些特殊情況下，壓縮后的體積甚至比Extra High還大。

;

說說相同點：

1.支持嵌入CUE

2.支持回放增益（與其說格式本身是否支持，不如說是播放器是否支持，呵呵）

3.支持錯誤檢測

還有一些習以為常的共同點就不說了，大家都把目光放在了他們的不同點上，其實他們本質上的差距并不大。

說說不同點：

多聲道的支持：

APE不支持，FLAC，TAK支持

兼容性：

APE和FLAC都是開源的，TAK不是開源的。

開不開源與我們普通用戶無關，但是開源與否從側面影響了兼容性。

可以說FLAC的兼容性一向是最好的，不過APE和FLAC比也差不到哪里去。悲劇的是TAK，只支持Windows，想在Linux上播放還得通過Wine模擬運行，關鍵是其在移動設備上的支持率為0%。目前有foobar2000，WinAmp，百度音樂（千千靜聽），AirPlay等播放器可以播放TAK。只能期待其早日開源，改善移動設備上的兼容性。到時候我可能要像某些FLAC的瘋狂追隨者一樣，把所有的無損音頻都轉換為TAK格式，笑：）。

錯誤處理：

網絡上盛傳，APE用爆音處理錯誤，FLAC用禁音處理錯誤。

APE真的是用爆音處理嗎？答案是否定的。FLAC禁音效果就很好了嗎？答案依然是否定的。恰恰是這句無關緊要的輿論，被某些FLAC的支持者奉為真理，并出現了大范圍將APE轉為FLAC保存的舉動。如果說你是因為FLAC解碼速度快而決定使用FLAC，那我100%要支持你；如果你是因為這個輿論而產生了心理上的優(yōu)越感的話，那我100%要站出來否定你。

;

錯誤產生：

1.;;;;;;;編碼的時候發(fā)生錯誤

概率極低，一旦出現，不是你的硬盤有問題，就是內存有問題，當然不排除CPU出了問題的可能性，本人至今從未遇到。

2.;;;;;;;保存在硬盤里的數據發(fā)生突變

概率極低，一旦出現，你該檢測一下硬盤是否出現了壞道之類的問題，做好數據備份的工作吧，默哀。

3.;;;;;;;網絡傳輸過程中發(fā)生數據錯誤

這在錯誤的產生中至少占了99.9%的比重，即便如此，發(fā)生的概率還是很低的，跟網絡上下載的RAR發(fā)生錯誤，無法解壓的概率一樣。

一句話總結：錯誤發(fā)生的概率很低很低。

;

錯誤檢測：

只要錯誤能檢測出來，即便發(fā)生了錯誤又如何？

APE，FLAC，TAK壓縮的的時候都可以保存原始音頻數據的md5，發(fā)生了任何錯誤都能通過對比md5檢測出來，保證了音頻數據的完整性。

而每一幀的音頻數據都保存了效驗碼，通過計算，就能找出錯誤的發(fā)生的具體位置。

APE的命令：mac;文件名;-v

FLAC的命令：flac -t;文件名

TAK的命令：takc -t;文件名

你不知道這些命令也沒關系，其實你已經不知不覺中檢測了無數次了。最簡單的方法就是用foobar2000轉換為其他格式，看是否提示錯誤。

一句話總結：任何的錯誤都能被檢測出來。

順便說下WAV是不支持錯誤檢測的，即便發(fā)生了數據改變也沒人知道，這不利于音頻的長期保存與傳播，趁早轉為無損格式吧，笑: )

;

錯誤處理：

APE：發(fā)出錯誤信息，直接停止解碼。

FLAC：發(fā)出錯誤信息，將錯誤的幀靜音處理，幀長度25ms~92ms（取決于編碼參數），繼續(xù)后面的解碼。

TAK：發(fā)出錯誤信息，將錯誤的幀靜音處理，幀長度95ms~250ms（取決于編碼參數），繼續(xù)后面的解碼。

;

雖然錯誤的產生如此不易，但是人工的模擬錯誤產生還是很簡單的。

使用文本編輯器（比如Notepad++）打開音頻文件，將其中某一位修改（不要修改太前面的數據，那些都是文件頭，不是音頻數據本身，修改了也沒用），然后保存。

開始測試：

APE

;

foobar2000播放提示：

;

相當直截了當，然后就播放下一首了。

foobar2000轉碼提示：

;

只能轉換到一半，后面直接丟失。

網上有這么一句話，ape一個錯誤，整軌報廢，我不知道你這個整軌是怎么定義的。如果這個整軌說的是專輯的話，那自然只廢了其中一首歌。如果這個整軌指的是單曲的話，你喜歡FLAC的禁音的處理方式，APE也一樣能做到。編寫一個CUE，將音頻分為前后兩段，把錯誤的那部分屏蔽掉，然后將前后兩段用foobar2000轉為整軌就好了。

但是APE的幀長度比FLAC，TAK大的多了，Fast = Normal = High = 2000ms，Extra High = 8500ms，Insane = 50000ms。這也是為什么Insane級別在定位時間的時候那么慢，但是順序播放不卡的根本原因。與High對比，Insane解碼速度變?yōu)镠igh的五分之一，幀長度變?yōu)镠igh的25倍，結果就是定位所需時間變?yōu)樵瓉淼?25倍，不卡才怪。在我看來APE的Extra High;和;Insane這兩個參數都應該果斷拒絕使用。

FLAC

;

foobar2000播放時不提示錯誤，但只要認真聽，差別很明顯。

;

這是音頻的錯誤部分頻譜截圖，知道人耳聽到這92ms的靜音時是什么感覺嗎？其實就是爆音，破音，卡頓的感覺，一耳朵就能聽出來，不信你試試。（25ms也一樣）

foobar2000轉碼提示：

;

轉碼后音頻長度完整，禁音處理了錯誤部分。

保存的FLAC發(fā)生了錯誤，不用擔心它在不知不覺中偷偷靜音，影響收藏的品質，因為在轉換的時候，他會直截了當的告訴你發(fā)生了錯誤的。當然那些所謂FLAC會把原始音頻中的爆音用禁音處理，這種荒謬的說法也是完全錯誤的。

要是哪個FLAC的粉絲心血來潮，決定把無損歌曲都轉為FLAC-Level8格式保存，又不知道這個錯誤提示的含義，直接忽略了，那簡直是一場災難。還好錯誤發(fā)生的概率很低很低，而且當下FLAC的資源并不占統(tǒng)治地位。喜歡FLAC這個格式的童鞋務必提高警惕。

TAK

;

foobar2000播放提示：

;

跟APE一樣的結果，這是foobar2000的處理方式吧

foobar2000轉碼提示：

;

與FLAC結果一樣，轉碼后音頻長度完整。250ms的幀長度，禁音時間長了，可以明顯聽出一段聲音沒了。轉換格式時，務必留意錯誤提示。

;

總結：

在高保真音頻領域，錯誤檢測是必備的，這是APE，FLAC，TAK的共同點。不同點在于對錯誤的處理方式。容錯性對于音頻收藏來說，沒有任何意義，50ms左右的禁音，完全在人耳的分辨范圍之內，最終結果都是重新尋找更好的音源。

那么容錯性就沒有其存在的價值了么，當然不是的，在高清視頻領域，FLAC作為優(yōu)秀的無損音頻格式，自然是所向霹靂的，APE不支持容錯性和多聲道，注定要被淘汰。

編碼速度：

這是一項沒什么意義的的比較，其權重最多不超過1%

在我看來，只要不是慢的說不過去，就完全不關心這一項。音頻是用來反復播放的，不是用來反復編碼的。

;

我們來看下國外的ktf大神寫的，一篇關于無損音頻比較的文章：

http://www.hydrogenaudio.org/forums/index.php?showtopic=98665

這是我目前見過的唯一一篇對于編碼，解碼，以及體積關系研究透徹，具有參考價值的文章。

（這篇文章其實還有新版本，但是TAK作者認為不如這個版本準確，我也是這么認為的。）

完整文章的pdf下載：

http://pan.baidu.com/share/link?shareid=331857304;uk=1494056105

那些，直接把APE，FLAC，TAK等等無損格式編碼，解碼速度定義為快慢之類的文章，沒有任何參考價值。

無損格式編碼速度的比較圖：

;

;;;;;;;橫軸表示編碼速度，越往右，越快越好。

;;;;;;;縱軸表示文件體積，越往下，越小越好。

越是靠近右下方的格式，越優(yōu)秀，越是靠近左上方的格式表現越差。

你可以看到不同的格式都有好幾個點，這代表了不同的參數，比如：

FLAC:;-0; -1; -2; -3; -4; -5; -6; -7; -8

TAK:;-p0; -p0e; -p0m; -p1; -p1e; -p1m; -p2; -p2e; -p2m; -p3; -p3e; -p3m; -p4; -p4e; -p4m

APE:;-c1000; -c2000; -c3000; -c4000; -c5000

;

這才是真正有意義的對比評測。

可以看出，TAK在編碼的速度上平均來看是最好的。

APE和FLAC在大部分的編碼范圍內不具可比性，如果你硬要比，那也是APE比FLAC優(yōu)秀，APE Fast與FLAC level 5的編碼速度接近，但APE體積更小，FLAC Level8的編碼速度比APE High;還要慢的多（基本慢了一倍）。

前面我也說了這一部分真心無所謂，隨便看看就好，權重最多不超過1%

重中之重——解碼速度與體積：

終于寫到這里了，這兩項才是比較的重點，至少要占98%的權重。

無損格式解碼速度的比較圖：

;

;;;;;;;橫軸表示解碼速度，越往右，越快越好。

;;;;;;;縱軸表示文件體積，越往下，越小越好。

越是靠近右下方的格式，越優(yōu)秀，越是靠近左上方的格式表現越差。

你可以看到不同的格式都有好幾個點，這代表了不同的參數，比如：

FLAC:;-0; -1; -2; -3; -4; -5; -6; -7; -8

TAK:;-p0; -p0e; -p0m; -p1; -p1e; -p1m; -p2; -p2e; -p2m; -p3; -p3e; -p3m; -p4; -p4e; -p4m

APE:;-c1000; -c2000; -c3000; -c4000; -c5000

從這張圖，就可以看出，真正優(yōu)秀的格式只有FLAC和TAK，FLAC在稍大體積的領域里獨霸一方，TAK在稍小體積的領域里力壓APE，TAK p2與APE Normal;體積接近，TAK p3與APE High體積接近，TAK p4的體積介于APE High和APE Extra High之間，卻有著4倍于APE High的解碼速度。

;

FLAC level8的解碼速度比TAK p4m快了46%，體積比TAK p4m大了(55.5-53.0)/53.0 = 4.7%

TAK用46%的解碼速度來換取4.7%的體積大小，這是否有價值呢？

問題在于解碼速度與文件體積并沒有直接的可比性。

我們設解碼的運算量為C，系統(tǒng)和其他軟件的運算量為S，文件的體積為V，

那么，我們的期望值：

E = (C+S)*V

E值越小，這個格式越優(yōu)秀

說白了C+S體現的是功耗，或者說是耗電量，我還沒把屏幕，顯卡，外放之類的算進來呢，呵呵。

;

假設FLAC level8的運算量為1，TAK p4m的體積為1

那么TAK p4m的運算量為1.46，FLAC level8的體積為1.047

我們讓E(FLAC level8) = E(TAK p4m)

(1+S)*1.047 = (1.46+S)*1

S = 8.79

當系統(tǒng)和其他軟件的運算量大于FLAC level8解碼運算量的9倍左右的時候，或者說FLAC level8解碼的運算量小于系統(tǒng)和其他軟件的運算量的1/9的時候，TAK p4m將更有優(yōu)勢，反之FLAC level8更有優(yōu)勢。

我們知道，系統(tǒng)和其他軟件的運算量不可能無限大，這受制于CPU的速度，CPU的使用率最大只能是100%。我們假定性能一般的機器，一邊聽音樂一邊干著其他事情時（比如瀏覽網頁，QQ，玩游戲等等），CPU的平均使用率為30%，那么：

FLAC level8解碼的CPU占用率;= 30% / (TAK p4m的運算量+S) = 0.3/(1.46+8.79) = 2.93%

也就是說，當FLAC level8解碼的CPU占用率小于2.93%時，TAK p4m更值得推薦，反之FLAC level8更值得推薦。

這還不夠形象，我們應該把CPU的占用率轉換為解碼的速率

FLAC level8解碼的速率;= 1/(2.93%) = 34.2

這34.2什么意思呢？

34.2的意思就是你的CPU滿載時，每秒能夠解碼34.2秒的FLAC level8音頻數據。

這個值的比較對象就是;歌曲總時間長度;/;解碼所需時間

CPU越快，解碼速度就越快，解碼的消耗就越顯得無足輕重，當解碼FLAC level8的速度超過34.2時，TAK p4m更值得推薦，反之FLAC level8更值得推薦。其實34.2是一個相當小的值，十年前的電腦都能輕松達到。

（后面我會測試FLAC level8的解碼速度）

;

我們順便測試下APE High和FLAC level8的對比吧，為什么是High這個參數呢？因為High這個參數所需的S值最小，換句話說APE High在反超FLAC之前，就已經先超越了Normal和Fast。

E(FLAC level8) = E(APE High)

(1+S)*1.042 = (6.14+S)*1

S = 121.4

可以看到S值相當大，那么當今的CPU處理速度能否達到這個值呢？我們后面將會看到。

FLAC level8解碼的CPU占用率;= 30% / (APE High的運算量+S) = 0.3/(6.14+121.4) = 0.235%

FLAC level8解碼的速率;= 1/( 0.235%) = 425.1

當CPU解碼FLAC level8的速度超過425.1時，APE High更值得推薦，反之FLAC level8更值得推薦。

那么，問題的關鍵就在于425.1的解碼速度，當下的CPU性能是否能夠達到呢？

;

讓我們來測試一下吧：

隨機選了20首無損，轉為整軌WAV，總時長1：25：37，再分別轉換為對應格式，記錄解碼的時間和文件體積：

格式

體積

體積比

解碼時間

解碼速度

推薦程度

WAV

864MB

167.1%

/

/

不推薦

FLAC-level0

592MB

114.5%

11.5s

446.7

不推薦

FLAC-level8

536MB

103.7%

11.5s

446.7

推薦

APE-Fast

535MB

103.5%

45s

114.2

不推薦

APE-High

520MB

100.6%

67s

76.7

推薦

TAK-p4m

517MB

100.0%

18s

285.4

推薦

解碼速度;=;總時長;/;解碼時間

可以看到，相對于WAV來說，并沒有達到55%左右的壓縮比，樓主隨機選出的這20首歌的壓縮率大概在60%左右，這與音源的飽滿程度有關。

不同格式間的差距都跟ktf做的測試差不多，不過我的CPU比他好點，所以解碼速度都按比例提高了。

FLAC-level0和APE-Fast都不推薦，拿FLAC-level8作為比較對象，一個體積臃腫，一個解碼速度慢，顯然FLAC-level8更好。

這里的解碼速度只是單線程的速度，樓主筆記本CPU為Intel Core i5-2430M，雙核4線程，根據notebookcheck網站的測試，單線程Cinebench R10 32Bit;得分3787，多線程得分8222，那么多線程FLAC-level8的解碼速度就是：

446.7 * 8222 / 3787 = 969.8

（解碼速度僅從側面體現CPU的運算能力，并非一定要單線程）

;http://www.notebookcheck.net/Mobile-Processors-Benchmarklist.2436.0.html

;

969.8遠超34.2（上文中計算的結果），接近30倍，顯然TAK p4m是更好的選擇，即便是十年前（2003年）的電腦，TAK p4m依然比FLAC-level8更值得推薦。

969.8是425.1（上文中計算的結果）的2.3倍，顯然APE High已經反超FLAC-level8了，不過跟TAK自然是沒得比。

那么CPU達到什么程度的電腦，APE High比FLAC-level8更值得推薦呢？

簡單的算下：8222 * 425.1 / 969.8 = 3604

也就是說在Cinebench R10 32Bit;多線程得分超過3604的電腦上，APE High比FLAC更值得推薦。

這個分值大概就是桌面的Intel Pentium E2100系列，AMD速龍雙核，移動平臺Intel Celeron Dual-Core T3100，AMD Turion X2 Ultra的水平。也就是2007年主流桌面配置，2008年主流筆記本配置的水平。

;

那我們順便算下APE High的最低需求：

I5睿頻到2800MHz，APE High的解碼速度為76.7，那么：

2800MHz / 76.7 = 36.5MHz

考慮到需要運行作系統(tǒng)以及多年來CPU同頻率性能的提升，我們乘個5倍好了

36.5MHz * 5 = 182.5MHz

還是前面舉得那個例子，Nokia N73（220MHz ARM9;單核CPU）都能播放APE。所以性能早已不是問題。

;

隨著計算機的發(fā)展，解碼消耗的CPU越來越顯得微不足道，解碼速度的權重變得越來越小。過個三五年，即便是移動設備領域，FLAC的解碼速度優(yōu)勢（或者說是省電優(yōu)勢）也將變得無足輕重。

;

高度總結：

FLAC：體積稍大，但擁有1.4倍于TAK的解碼速度，兼容性良好，移動設備的最佳選擇。推薦level8參數。

TAK：與APE相似的體積大小，略輸FLAC的解碼速度，可惜移動設備的兼容性為0%，PC的最佳選擇。推薦-p4m參數。

APE：與TAK相似的體積大小，解碼速度只有TAK的四分之一，兼容性良好。推薦-c3000參數（即High），不要使用;-c4000，-c5000這兩個參數。

;;;;;;;上面三句話已經高度概括了重點，沒有提到的都是無關緊要的不同點。各種無損格式本質上大同小異，不必太過執(zhí)著。

;

真?zhèn)螣o損的檢驗：

說到無損的檢測，個人推薦用auCDtect Task Manager這個工具，可以直接檢驗各種無損格式很方便。

經常看到一些高手批判這類檢測工具，說它們測的不準，然后就是各種貶低。我只想說一味的否定一個東西存在的價值本身就是一個錯誤。確實，這些工具對于高碼率的AAC，表現的無力，但是網絡上大部分的偽無損都是無知的小白用MP3轉來的。很多小白在收藏，傳播無損的時候也不在意真?zhèn)巍＿@已經不是用不用工具來檢測無損的問題了。這是大家分享的時候是否檢測真?zhèn)蔚膯栴}。如果大家在分享無損歌曲的時候都能先用auCDtect Task Manager檢測下真?zhèn)蔚脑挘腋艺f網絡上的偽無損至少能減少90%。

當然工具只能作為你判斷真?zhèn)螣o損的依據，不能作為你斷定歌曲真?zhèn)蔚睦碛伞?/p>

很多早期的CD都沒有高頻部分，還有就是很多純音樂也沒有高頻部分被軟件誤判為MP3。經過auCDtect Task Manager檢測，所有CD概率在90%以下，或者被判定為MP3的，除非你很確定歌曲的來源，其他的都應該通過查看頻譜以及試聽來進一步鑒定。日常聽歌過程中發(fā)現某些音質較差的歌曲也可以看下頻譜，尋找更好的音源。

auCDtect Task Manager本身就能查看頻譜，相當的方便。

看頻譜其實也沒什么難度，看多了就有經驗了，比如說高頻部分是哪個位置被切掉，是不是干凈利落的突然黑掉一塊，高頻是否有鋸齒感，是否有空洞等等。

（順便說下個人經驗，百度音樂，酷我，酷狗里的無損都是網絡上的無損資源，沒有經過任何檢查，大概8首里就有1首偽無損。當然，這個比例可能是我缺的無損都比較偏門的原因，相比之下QQ音樂要好得多，雖然它的資源也是來自于網絡，但是經過了檢查）

關于auCDtect Task Manager的使用，以及真?zhèn)螣o損鑒別的詳細介紹，可以看看我的這篇文章：

http://blog.sina.com.cn/s/blog_637d7cd80101pzx4.html

;

附錄：

foobar2000;漢化版博主：http://blog.sina.com.cn/go2spa

foobar2000;v1.2.9;Final;漢化版;B版（支持APE，FLAC，TAK）:;http://pan.baidu.com/share/link?shareid=3189882988;uk=1494056105

Foobar2000;轉換為APE格式推薦設置：

;

Foobar2000;轉換為TAK格式推薦設置：

TAK_2.3.0：http://pan.baidu.com/share/link?shareid=3187574417;uk=1494056105

;

關于主流有損格式橫評的文章：

http://blog.sina.com.cn/s/blog_637d7cd80101p1j6.html

;

;

終于看完了，如果你覺得本文寫的不錯，看了之后有所收獲，歡迎轉載。